Post not yet marked as solved
I've had people reaching out to me that their keyboard extensions started disappearing in iOS 17. As I investigated one, I found that using "se." (Swedish top domain) as bundle identifier prefix causes the keyboard to disappear.
I wrote more about this issue here, and have reported it to the Feedback Assistant:
https://keyboardkit.com/blog/2024/02/12/keyboards-disappear-in-ios-17
Post not yet marked as solved
Does this approach still work for you? I try it on a tvOS 17 simulator, and it always resets to the first item, even if I say that the default focus index should be 2.
Post not yet marked as solved
@MaksGal This unfortunately doesn't work in iOS 16 and later. If anyone finds a solution, I'd love to hear about it.
In extension's Info.plist file, you have a "PrimaryLanguage" key under "NSExtension/NSExtensionAttributes".
If you set this to "mul", the extension will display "Multiple languages" instead of English.
It will however not show the current locale.
I thought I had the same problem in Xcode 12.0.1, where I updated a @State property without anything happening.
I then added some print-outs and found the problem to be even more bizarre than the UI not updating. I fetched data from an external api, decoded it and set the optional state to the result, but when I printed the non-nil state value in didSet, the value was printed as nil.
So, the @State property value didn't even seem to get applied, even though I set it to a non-nil value.
I then replaced @State with an @ObservableObject and got some interesting prints that @State didn't provide. It turned out that I wasn't performing the network completion on the main queue, which the observable object clearly printed out wasn't allowed.
After adjusting the code so the completion was performed on the main queue, everything started working, but the @State didSet still printed nil.
Post not yet marked as solved
Hi again,I did proceed with the timer-based bug fix hack and managed to find a solution with two small flaws:Since the bug fix is timer-based, there is a tiny risk that the user enters text just as the text position is changed. If so, the text will be incorrectly inserted. However, I have not been able to end up in this state, so I think it's pretty solid.Since the bug fix works by adjusting the text cursor position, it will close any presented text callouts. I tried to solve this, but the very nature of the bug fix makes it very hard to fix.This timer is part of a keyboard library that I'm building (https://github.com/danielsaidi/KeyboardKit). You can find the timer class here: https://github.com/danielsaidi/KeyboardKit/tree/master/KeyboardKit/AutocompleteI really don't want to have to resort to this hack, but it's the best that I could come up with for now. I hope that the UIKit bug that causes these problems could be fixed soon.
Post not yet marked as solved
It has been three years since this was reported, but I am still experiencing the same problem in Xcode 10.2.1. It occurs both in the simulator and on real devices and I have found no way to solve it. I can recreate it both in my custom keyboard project and in a brand new test project.Bacially, "textWillChange" and "textDidChange" are not called when you type with an external keyboard, nor when you send text to the text document proxy like this:textDocumentProxy.insertText("something")I tried starting a scheduled timer that trigges every second, but the information in the text document proxy doesn't change, even if I insert text into it between the timer ticks.However, changing the cursor position causes these functions to be called and also updates the document proxy information. As a test, I therefore tried doing the following in my scheduled timer:textDocumentProxy.adjustTextPosition(byCharacterOffset: 1)
textDocumentProxy.adjustTextPosition(byCharacterOffset: -1)This doesn't work, since the proxy must apply the change. However, if I toggle the value and adjust the position 1, -1, 1 etc. the functions are properly called and the proxy information is updated.However, this is not an acceptable way of solving this problem. The document proxy should trigger these functions as the user types, or provide other means to detect typing.
